Some time ago, I discussed custom dialog classes. You can specify that a dialog template use your custom dialog class by putting the custom class’s name in the CLASS statement of the dialog template. A customer tried doing that but it crashes with a stack overflow.

// Dialog template

IDD_AWESOME DIALOGEX 0, 0, 170, 62
STYLE DS_SHELLFONT | DS_MODALFRAME | WS_POPUP | WS_CAPTION
CAPTION "I'm so awesome"
CLASS "MyAwesomeDialog"
FONT 8, "MS Shell Dlg", 0, 0, 0x1
BEGIN
    ICON            IDI_AWESOME,IDC_STATIC,14,14,20,20
    LTEXT           "Whee!",IDC_STATIC,42,14,114,8
    DEFPUSHBUTTON   "OK",IDOK,113,41,50,14,WS_GROUP
END

// Custom dialog class procedure
// Note: This looks ugly but that's not the point.
LRESULT CALLBACK CustomDlgProc(HWND hwnd, UINT message,
                               WPARAM wParam, LPARAM lParam)
{
    if (message == WM_CTLCOLORDLG) {
        return (LRESULT)GetSysColorBrush(COLOR_INFOBK);
    }
    return DefDlgProc(hwnd, message, wParam, lParam);
}

void Test()
{
    // Register the custom dialog class
    WNDCLASS wc{};
    GetClassInfo(nullptr, WC_DIALOG, &wc);
    wc.lpfnWndProc = CustomDlgProc;
    wc.lpszClassName = TEXT("MyAwesomeDialog");
    RegisterClass(&wc);

    // Use that custom dialog class for a dialog
    DialogBox(hInstance, MAKEINTESOURCE(IDD_AWESOME), hwndParent,
              CustomDlgProc);
}

Do you see the problem?

The problem is that the code uses the CustomDlgProc function both as a window procedure and as a dialog procedure.

When a message arrives, it goes to the window procedure. This rule applies regardless of whether you have a traditional window or a dialog. If you have a standard dialog, then the window procedure is Def­Dlg­Proc, and that function calls the dialog procedure to let it respond to the message. If the dialog procedure declines to handle the message, then the Def­Dlg­Proc function does some default dialog stuff.

Creating a custom dialog class means that you want a different window procedure for the dialog, as if you had subclassed the dialog. The custom window procedure typically does some special work, and then it passes messages to Def­Dlg­Proc when it wants normal dialog behavior.

If you use the same function as both the window procedure and the dialog procedure, then when the function (acting as a window procedure) passes a message to Def­Dlg­Proc, the Def­Dlg­Proc function will call the dialog procedure, which is also Custom­Dlg­Proc. That function doesn’t realize that it’s now being used as a dialog procedure, so it is expected to return TRUE or FALSE (depending on whether it decided to handle the message). It thinks it is still a window procedure, so it passes the message to Def­Dlg­Proc, and the loop continues until you overflow the stack.

The idea behind custom dialog classes is that you have some general behavior you want to apply to all the dialogs that use that class. For example, maybe you want them all to use different default colors, or you want them all to respond to DPI changes the same way. Instead of replicating the code in each dialog procedure, you can put it in the dialog class window procedure.

But even if you are using a custom dialog class, your dialog procedure should still be a normal dialog procedure. That dialog procedure is the code-behind for the dialog template, initializing the controls in the template, responding to clicks on the controls in the template, and so on.

The post On the proper usage of a custom Win32 dialog class appeared first on The Old New Thing.

If you've ever used a 3D printer, you may recall the wondrous feeling when you first printed something you could have never sculpted or built yourself. Download a model file, load some plastic filament, push a button, and almost like magic, a three-dimensional object appears. But the result isn't polished and ready for mass production, and creating a novel shape requires more skills than just pushing a button. Interestingly, today's AI coding agents feel much the same way.

Since November, I have used Claude Code and Claude Opus 4.5 through a personal Claude Max account to extensively experiment with AI-assisted software development (I have also used OpenAI's Codex in a similar way, though not as frequently). Fifty projects later, I'll be frank: I have not had this much fun with a computer since I learned BASIC on my Apple II Plus when I was 9 years old. This opinion comes not as an endorsement but as personal experience: I voluntarily undertook this project, and I paid out of pocket for both OpenAI and Anthropic's premium AI plans.

Throughout my life, I have dabbled in programming as a utilitarian coder, writing small tools or scripts when needed. In my web development career, I wrote some small tools from scratch, but I primarily modified other people's code for my needs. Since 1990, I've programmed in BASIC, C, Visual Basic, PHP, ASP, Perl, Python, Ruby, MUSHcode, and some others. I am not an expert in any of these languages—I learned just enough to get the job done. I have developed my own hobby games over the years using BASIC, Torque Game Engine, and Godot, so I have some idea of what makes a good architecture for a modular program that can be expanded over time.

In December, I used Claude Code to create a multiplayer online clone of <em>Katamari Damacy</em> called "Christmas Roll-Up." Credit: Benj Edwards

Claude Code, Codex, and Google's Gemini CLI, can seemingly perform software miracles on a small scale. They can spit out flashy prototypes of simple applications, user interfaces, and even games, but only as long as they borrow patterns from their training data. Much like a 3D printer, doing production-level work takes far more effort. Creating durable production code, managing a complex project, or crafting something truly novel still requires experience, patience, and skill beyond what today's AI agents can provide on their own.

And yet these tools have opened a world of creative potential in software that was previously closed to me, and they feel personally empowering. Even with that impression, though, I know these are hobby projects, and the limitations of coding agents lead me to believe that veteran software developers probably shouldn't fear losing their jobs to these tools any time soon. In fact, they may become busier than ever.

So far, I have created over 50 demo projects in the past two months, fueled in part by a bout of COVID that left me bedridden with a laptop and a generous 2x Claude usage cap that Anthropic put in place during the last few weeks of December. As I typed furiously all day, my wife kept asking me, "Who are you talking to?"

You can see a few of the more interesting results listed on my personal website. Here are 10 interesting things I've learned from the process.

1. People are still necessary

Even with the best AI coding agents available today, humans remain essential to the software development process. Experienced human software developers bring judgment, creativity, and domain knowledge that AI models lack. They know how to architect systems for long-term maintainability, how to balance technical debt against feature velocity, and when to push back when requirements don't make sense.

For hobby projects like mine, I can get away with a lot of sloppiness. But for production work, having someone who understands version control, incremental backups, testing one feature at a time, and debugging complex interactions between systems makes all the difference. Knowing something about how good software development works helps a lot when guiding an AI coding agent—the tool amplifies your existing knowledge rather than replacing it.

As independent AI researcher Simon Willison wrote in a post distinguishing serious AI-assisted development from casual "vibe coding," "AI tools amplify existing expertise. The more skills and experience you have as a software engineer the faster and better the results you can get from working with LLMs and coding agents."

With AI assistance, you don't have to remember how to do everything. You just need to know what you want to do.

<em>Card Miner: Heart of the Earth</em> is entirely human-designed, but it was AI-coded using Claude Code. It represents about a month of iterative work. Credit: Benj Edwards

So I like to remind myself that coding agents are software tools best used to enact human ideas, not autonomous coding employees. They are not people (and not people replacements) no matter how the companies behind them might market them.

If you think about it, everything you do on a computer was once a manual process. Programming a computer like the ENIAC involved literally making physical bits (connections) with wire on a plugboard. The history of programming has been one of increasing automation, so even though this AI-assisted leap is somewhat startling, one could think of these tools as an advancement similar to the advent of high-level languages, automated compilers and debugger tools, or GUI-based IDEs. They can automate many tasks, but managing the overarching project scope still falls to the person telling the tool what to do.

And they can have rapidly compounding benefits. I've now used AI tools to write better tools—such as changing the source of an emulator so a coding agent can use it directly—and those improved tools are already having ripple effects. But a human must be in the loop for the best execution of my vision. This approach has kept me very busy, and contrary to some prevailing fears about people becoming dumber due to AI, I have learned many new things along the way.

2. AI models are brittle beyond their training data

Like all AI models based on the Transformer architecture, the large language models (LLMs) that underpin today's coding agents have a significant limitation: They can only reliably apply knowledge gleaned from training data, and they have a limited ability to generalize that knowledge to novel domains not represented in that data.

What is training data? In this case, when building coding-flavored LLMs, AI companies download millions of examples of software code from sources like GitHub and use them to make the AI models. Companies later specialize them for coding through fine-tuning processes.

The ability of AI agents to use trial and error—attempting something and then trying again—helps mitigate the brittleness of LLMs somewhat. But it's not perfect, and it can be frustrating to see a coding agent spin its wheels trying and failing at a task repeatedly, either because it doesn't know how to do it or because it previously learned how to solve a problem but then forgot because the context window got compacted (more on that here).

<em>Violent Checkers</em> is a physics-based corruption of the classic board game, coded using Claude Code. Credit: Benj Edwards

To get around this, it helps to have the AI model take copious notes as it goes along about how it solved certain problems so that future instances of the agent can learn from them again. You also want to set ground rules in the claude.md file that the agent reads when it begins its session.

This brittleness means that coding agents are almost frighteningly good at what they've been trained and fine-tuned on—modern programming languages, JavaScript, HTML, and similar well-represented technologies—and generally terrible at tasks on which they have not been deeply trained, such as 6502 Assembly or programming an Atari 800 game with authentic-looking character graphics.

It took me five minutes to make a nice HTML5 demo with Claude but a week of torturous trial and error, plus actual systematic design on my part, to make a similar demo of an Atari 800 game. To do so, I had to use Claude Code to invent several tools, like command-line emulators and MCP servers, that allow it to peek into the operation of the Atari 800's memory and chipset to even begin to make it happen.

3. True novelty can be an uphill battle

Due to what might poetically be called "preconceived notions" baked into a coding model's neural network (more technically, statistical semantic associations), it can be difficult to get AI agents to create truly novel things, even if you carefully spell out what you want.

For example, I spent four days trying to get Claude Code to create an Atari 800 version of my HTML game Violent Checkers, but it had trouble because in the game's design, the squares on the checkerboard don't matter beyond their starting positions. No matter how many times I told the agent (and made notes in my Claude project files), it would come back to trying to center the pieces to the squares, snap them within squares, or use the squares as a logical basis of the game's calculations when they should really just form a background image.

To get around this in the Atari 800 version, I started over and told Claude that I was creating a game with a UFO (instead of a circular checker piece) flying over a field of adjacent squares—never once mentioning the words "checker," "checkerboard," or "checkers." With that approach, I got the results I wanted.

A screenshot of Benj's Mac while working on a <em>Violent Checkers</em> port for the Atari 800 home computer, amid other projects. Credit: Benj Edwards

Why does this matter? Because with LLMs, context is everything, and in language, context changes meaning. Take the word "bank" and add the words "river" or "central" in front of it, and see how the meaning changes. In a way, words act as addresses that unlock the semantic relationships encoded in a neural network. So if you put "checkerboard" and "game" in the context, the model's self-attention process links up a massive web of semantic associations about how checkers games should work, and that semantic baggage throws things off.

A couple of tricks can help AI coders navigate around these limitations. First, avoid contaminating the context with irrelevant information. Second, when the agent gets stuck, try this prompt: "What information do you need that would let you implement this perfectly right now? What tools are available to you that you could use to discover that information systematically without guessing?" This forces the agent to identify (semantically link up) its own knowledge gaps, spelled out in the context window and subject to future action, instead of flailing around blindly.

4. The 90 percent problem

The first 90 percent of an AI coding project comes in fast and amazes you. The last 10 percent involves tediously filling in the details through back-and-forth trial-and-error conversation with the agent. Tasks that require deeper insight or understanding than what the agent can provide still require humans to make the connections and guide it in the right direction. The limitations we discussed above can also cause your project to hit a brick wall.

From what I have observed over the years, larger LLMs can potentially make deeper contextual connections than smaller ones. They have more parameters (encoded data points), and those parameters are linked in more multidimensional ways, so they tend to have a deeper map of semantic relationships. As deep as those go, it seems that human brains still have an even deeper grasp of semantic connections and can make wild semantic jumps that LLMs tend not to.

Creativity, in this sense, may be when you jump from, say, basketball to how bubbles form in soap film and somehow make a useful connection that leads to a breakthrough. Instead, LLMs tend to follow conventional semantic paths that are more conservative and entirely guided by mapped-out relationships from the training data. That limits their creative potential unless the prompter unlocks it by guiding the LLM to make novel semantic connections. That takes skill and creativity on the part of the operator, which once again shows the role of LLMs as tools used by humans rather than independent thinking machines.

5. Feature creep becomes irresistible

While creating software with AI coding tools, the joy of experiencing novelty makes you want to keep adding interesting new features rather than fixing bugs or perfecting existing systems. And Claude (or Codex) is happy to oblige, churning away at new ideas that are easy to sketch out in a quick and pleasing demo (the 90 percent problem again) rather than polishing the code.

Flip-Lash started as a "Tetris but you can flip the board," but feature creep made me throw in the kitchen sink, losing focus. Credit: Benj Edwards

Fixing bugs can also create bugs elsewhere. This is not new to coding agents—it's a time-honored problem in software development. But agents supercharge this phenomenon because they can barrel through your code and make sweeping changes in pursuit of narrow-minded goals that affect lots of working systems. We've already talked about the importance of having a good architecture guided by the human mind behind the wheel above, and that comes into play here.

6. AGI is not here yet

Given the limitations I've described above, it's very clear that an AI model with general intelligence—what people usually call artificial general intelligence (AGI)—is still not here. AGI would hypothetically be able to navigate around baked-in stereotype associations and not have to rely on explicit training or fine-tuning on many examples to get things right. AI companies will probably need a different architecture in the future.

I'm speculating, but AGI would likely need to learn permanently on the fly—as in modify its own neural network weights—instead of relying on what is called "in-context learning," which only persists until the context fills up and gets compacted or wiped out.

Grapheeti is a "drawing MMO" where people around the world share a canvas. Credit: Benj Edwards

In other words, you could teach a true AGI system how to do something by explanation or let it learn by doing, noting successes, and having those lessons permanently stick, no matter what is in the context window. Today's coding agents can't do that—they forget lessons from earlier in a long session or between sessions unless you manually document everything for them. My favorite trick is instructing them to write a long, detailed report on what happened when a bug is fixed. That way, you can point to the hard-earned solution the next time the amnestic AI model makes the same mistake.

7. Even fast isn't fast enough

While using Claude Code for a while, it's easy to take for granted that you suddenly have the power to create software without knowing certain programming languages. This is amazing at first, but you can quickly become frustrated that what is conventionally a very fast development process isn't fast enough. Impatience at the coding machine sets in, and you start wanting more.

But even if you do know the programming languages being used, you don't get a free pass. You still need to make key decisions about how the project will unfold. And when the agent gets stuck or makes a mess of things, your programming knowledge becomes essential for diagnosing what went wrong and steering it back on course.

8. People may become busier than ever

After guiding way too many hobby projects through Claude Code over the past two months, I'm starting to think that most people won't become unemployed due to AI—they will become busier than ever. Power tools allow more work to be done in less time, and the economy will demand more productivity to match.

It's almost too easy to make new software, in fact, and that can be exhausting. One project idea would lead to another, and I was soon spending eight hours a day during my winter vacation shepherding about 15 Claude Code projects at once. That's too much split attention for good results, but the novelty of seeing my ideas come to life was addictive. In addition to the game ideas I've mentioned here, I made tools that scrape and search my past articles, a graphical MUD based on ZZT, a new type of MUSH (text game) that uses AI-generated rooms, a new type of Telnet display proxy, and a Claude Code client for the Apple II (more on that soon). I also put two AI-enabled emulators for Apple II and Atari 800 on GitHub. Phew.

Consider the advent of the steam shovel, which allowed humans to dig holes faster than a team using hand shovels. It made existing projects faster and new projects possible. But think about the human operator of the steam shovel. Suddenly, we had a tireless tool that could work 24 hours a day if fueled up and maintained properly, while the human piloting it would need to eat, sleep, and rest.

I used Claude Code to create a windowing GUI simulation of the Mac that works over Telnet. Credit: Benj Edwards

In fact, we may end up needing new protections for human knowledge workers using these tireless information engines to implement their ideas, much as unions rose as a response to industrial production lines over 100 years ago. Humans need rest, even when machines don't.

Will an AI system ever replace the human role here? Even if AI coding agents could eventually work fully autonomously, I don't think they'll replace humans entirely because there will still be people who want to get things done, and new AI power tools will emerge to help them do it.

9. Fast is scary to people

AI coding tools can turn what was once a year-long personal project into a five-minute session. I fed Claude Code a photo of a two-player Tetris game I sketched in a notebook back in 2008, and it produced a working prototype in minutes (prompt: "create a fully-featured web game with sound effects based on this diagram"). That's wild, and even though the results are imperfect, it's a bit frightening to comprehend what kind of sea change in software development this might entail.

Since early December, I've been posting some of my more amusing experimental AI-coded projects to Bluesky for people to try out, but I discovered I needed to deliberately slow down with updates because they came too fast for people to absorb (and too fast for me to fully test). I've also received comments like "I'm worried you're using AI, you're making games too fast" and so on.

Benj's handwritten game design note about a two-player <em>Tetris</em> concept from 2007. Credit: Benj Edwards

Regardless of my own habits, the flow of new software will not slow down. There will soon be a seemingly endless supply of AI-augmented media (games, movies, images, books), and that's a problem we'll have to figure out how to deal with. These products won't all be "AI slop," either; some will be done very well, and the acceleration in production times due to these new power tools will balloon the quantity beyond anything we've seen.

Social media tends to prime people to believe that AI is all good or all bad, but that kind of black-and-white thinking may be the easy way out. You'll have no cognitive dissonance, but you'll miss a far richer third option: seeing these tools as imperfect and deserving of critique but also as useful and empowering when they bring your ideas to life.

AI agents should be considered tools, not entities or employees, and they should be amplifiers of human ideas. My game-in-progress Card Miner is entirely my own high-level creative design work, but the AI model handled the low-level code. I am still proud of it as an expression of my personal ideas, and it would not exist without AI coding agents.

10. These tools aren't going away

For now, at least, coding agents remain very much tools in the hands of people who want to build things. The question is whether humans will learn to wield these new tools effectively to empower themselves. Based on two months of intensive experimentation, I'd say the answer is a qualified yes, with plenty of caveats.

We also have social issues to face: Professional developers already use these tools, and with the prevailing stigma against AI tools in some online communities, many software developers and the platforms that host their work will face difficult decisions.

Ultimately, I don't think AI tools will make human software designers obsolete. Instead, they may well help those designers become more capable. This isn't new, of course; tools of every kind have been serving this role since long before the dawn of recorded history. The best tools amplify human capability while keeping a person behind the wheel. The 3D printer analogy holds: amazing fast results are possible, but mastery still takes time, skill, and a lot of patience with the machine.

Read full article

Comments

Pharmaceutical executives are finally saying how they really feel about the extreme anti-vaccine agenda Health Secretary Robert F. Kennedy Jr. has been ruthlessly implementing—and it's not pretty.

According to reporting from Bloomberg at the J.P. Morgan Healthcare Conference that ended today in San Francisco, pharmaceutical executives who had previously been careful to avoid criticizing the Trump administration appear to have reached a breaking point, with Pfizer CEO Albert Bourla offering some of the most candid comments.

"I am very annoyed. I'm very disappointed. I'm seriously frustrated," Bourla said. "What is happening has zero scientific merit and is just serving an agenda which is political, and then antivax."

Last week, Kennedy and other health officials abruptly announced a mass overhaul of the childhood vaccine schedule, dropping the number of routine recommended vaccinations from 17 to 11. The drastic and unprecedented change bypassed all the scientific review and transparent decision-making processes that would normally underpin such changes, which would likely have taken months if not years.

Kennedy claimed that the move puts the US more in line with peer nations, but as an analysis by Stat News pointed out, the US is now an outlier, recommending significantly fewer vaccines than many other countries. Of 20 so-called peer countries that Stat compared, only one other country has a similarly low number of recommendations: Denmark.

Leading medical groups, including the American Academy of Pediatrics, are preparing a legal challenge to block the changes.

Waiting for the midterms

But pharmaceutical executives don't appear comforted by the pushback. "Today it may be childhood vaccines or mRNA, but tomorrow it’s everything," Noubar Afeyan, co-founder and chairman of Moderna, maker of mRNA vaccines, said. "We have to say not just 'why is this happening?,' but 'Where will it stop?'"

As a bad flu season is underway, Dean Li, president of Merck Research Laboratories, noted that the anti-vaccine rhetoric is hitting seasonal flu shots. “With the pressure on vaccination, I cannot foresee flu vaccination increasing in this country over the next three years,” he said in a presentation.

Sanofi Chief Executive Paul Hudson had a similarly pessimistic outlook. "It’s clear this administration has a particular sensitivity around vaccination, and indeed pediatric vaccination,” Hudson said. "I’m asked all the time 'what are you going to do to fix this?,' and the truth is we just need to stay extremely objective and continue presenting the evidence. There’s really very little else we can do," except wait for the midterm elections, he said.

"We will have to maintain a steely focus on the long-term future of vaccines and deal with any uncertainty around vaccine coverage rates in the short-term based on misinformation, Facebook posts, and statements from the top," he said.

Bourla also worried about the conditions Kennedy is creating to attack drug makers. Kennedy, who is an environmental lawyer with no scientific or medical background, has profited from lawsuits against vaccine makers, as have many of his allies and advisors. "There is also a lot of plaintiffs' playbook there," Bourla said. "Everybody will start litigating."

Read full article

Comments

Freedom of speech is a foundational principle of healthy democracies and hence a primary target for aspiring authoritarians, who typically try to squash dissent. There is a point where the threat from authorities is sufficiently severe that a population will self-censor rather than risk punishment. Social media has complicated matters, blurring traditional boundaries between public and private speech, while new technologies such as facial recognition and moderation algorithms give authoritarians powerful new tools.

Researchers explored the nuanced dynamics of how people balance their desire to speak out vs their fear of punishment in a paper published in the Proceedings of the National Academy of Sciences.

The authors had previously worked together on a model of political polarization, a project that wrapped up right around the time the social media space was experiencing significant changes in the ways different platforms were handling moderation. Some adopted a decidedly hands-off approach with little to no moderation. Weibo, on the other hand, began releasing the IP addresses of people who posted objectionable commentary, essentially making them targets.

"We were seeing a lot of experimentation in the social media space, so this study started as a question," co-author Joshua Daymude of Arizona State University told Ars. "Why are these companies doing such dramatically different things, if ostensibly they're all social media companies and they all want to be profitable and have similar goals? Why are some going one way and others going another?"

Daymude and his co-authors also noticed similar dynamics at the nation-state level in terms of surveillance, monitoring, and moderation. "Russia, for the longest time, was very legalistic: 'Let's enumerate every bad thing we can think of so that if you do anything even remotely close, we can get you on one of these statutes that we've invented,'" said Daymude. "China was the opposite. They refused to tell you where the red line was. They just said, 'Behave yourself or else.' There's a famous essay that calls this 'The Anaconda in the Chandelier': this scary thing that might fall on you at any moment so you behave yourself."

The US has adopted more of a middle ground approach, essentially letting private companies decide what they wanted to do. Daymude and his co-authors wanted to investigate these markedly different approaches. So they developed a computational agent-based simulation that modeled how individuals navigate between wanting to express dissent versus fear of punishment. The model also incorporates how an authority adjusts its surveillance and its policies to minimize dissent at the lowest possible cost of enforcement.

"It's not some kind of learning theory thing," said Daymude. "And it's not rooted in empirical statistics. We didn't go out and ask 1000 people, 'What would you do if faced with this situation? Would you dissent or self-censor?' and then build that data into the model. Our model allows us to embed some assumptions about how we think people behave broadly, but then lets us explore parameters. What happens if you're more or less bold? What happens if punishments are more or less severe? An authority is more or less tolerant? And we can make predictions based on our fundamental assumptions about what's going to happen."

Let one hundred flowers bloom

According to their model, the most extreme case is an authoritarian government that adopts a draconian punishment strategy, which effectively represses all dissent in the general population. "Everyone's best strategic choice is just to say nothing at this point," said Daymude. "So why doesn't every authoritarian government on the planet just do this?" That led them to look more closely at the dynamics. "Maybe authoritarians start out somewhat moderate," he said. "Maybe the only way they're allowed to get to that extreme endpoint is through small changes over time."

Daymude points to China's Hundred Flowers Campaign in the 1950s as an illustrative case. Here, Chairman Mao Zedong initially encouraged open critiques of his government before abruptly cracking down aggressively when dissent got out of hand. The model showed that in such a case, dissenters' self-censorship gradually increased, culminating in near-total compliance over time.

But there's a catch. "The opposite of the Hundred Flowers is if the population is sufficiently bold, this strategy doesn't work," said Daymude. "The authoritarian can't find the pathway to become fully draconian. People just stubbornly keep dissenting. So every time it tries to ramp up severity, it's on the hook for it every time because people are still out there, they're still dissenting. They're saying, 'Catch us if you dare.'"

The takeaway: "Be bold," said Daymude. "It is the thing that slows down authoritarian creep. Even if you can't hold out forever, you buy a lot more time than you would expect."

That said, sometimes a bit of self-censorship can be a net positive. "I think the time and situation in which this paper has been published and our major governmental examples will evoke a primarily political interpretation of what we're talking about here," said Daymude. "But we tried to be clear that this doesn't have to be some adversarial oppressive regime versus freedom loving people. Self-censorship is not always a bad thing. This is a very general mathematical model that could be applicable to lots of different situations, including discouraging undesirable behavior."

Daymude draws an analogy to traffic laws, notably speed limits. Their model looked at two different forms of punishment: uniform and proportional. "Uniform is anything over the line gets whacked the same," said Daymude. "It doesn't matter if you were a little bad or very bad, the punishment is identical for everyone. With the proportional approach, the punishment fits the crime. You sped 10 miles an hour over the limit, that's a small fine. You sped 100 miles an hour over, this is reckless endangerment."

What he and his co-authors found intriguing is that different subjects self-censor more strongly in each of those two punishment scenarios. "For uniform punishment, it's the moderate folks who only wanted to dissent a little bit who self-censor because it's just not worth it to stick their neck out," said Daymude. "Very extreme dissenters stick their neck out and say, 'It doesn't matter. You can punish me. This is still worth it.' In the proportional regime, this flips. It's the moderates who do what they want. And no one expresses dissent over a certain amount. Yeah, we all speed a little bit, but we have this norm: we're all going to speed a moderate amount over the limit, and then we're going to stop. It's not safe, it's not acceptable, to go beyond this."

Daymude is aware that there are limitations to this agent-based approach, but insists it can still yield useful insights. "With a mechanistic model like this, you can really tie outcomes to explanations," said Daymude. "In the artificial world of my model, when tolerance moves like this, the population changes like this, and I can tell you it is because of that change and not because of the hundreds of other things that might've been going on in someone else's head."

The next step would be to design an empirical study that could test their working hypothesis. "I am not under any fiction that everything in this paper is absolutely true in the real world," said Daymude. "But it makes it very clear what matters and what doesn't, and what the phases of behavior are. There's compliance, then self-censorship, and defiance, and it happens in this way. These phases can disappear if boldness is not sufficient. So I see this not in competition with, but complementary to the other kinds of research in this area."

DOI: PNAS, 2025. 10.1073/pnas.2508028122  (About DOIs).

Read full article

Comments

On Saturday, tech entrepreneur Siqi Chen released an open source plugin for Anthropic's Claude Code AI assistant that instructs the AI model to stop writing like an AI model. Called "Humanizer," the simple prompt plugin feeds Claude a list of 24 language and formatting patterns that Wikipedia editors have listed as chatbot giveaways. Chen published the plugin on GitHub, where it has picked up over 1,600 stars as of Monday.

"It's really handy that Wikipedia went and collated a detailed list of 'signs of AI writing,'" Chen wrote on X. "So much so that you can just tell your LLM to ... not do that."

The source material is a guide from WikiProject AI Cleanup, a group of Wikipedia editors who have been hunting AI-generated articles since late 2023. French Wikipedia editor Ilyas Lebleu founded the project. The volunteers have tagged over 500 articles for review and, in August 2025, published a formal list of the patterns they kept seeing.

Chen's tool is a "skill file" for Claude Code, Anthropic's terminal-based coding assistant, which involves a Markdown-formatted file that adds a list of written instructions (you can see them here) appended to the prompt fed into the large language model (LLM) that powers the assistant. Unlike a normal system prompt, for example, the skill information is formatted in a standardized way that Claude models are fine-tuned to interpret with more precision than a plain system prompt. (Custom skills require a paid Claude subscription with code execution turned on.)

But as with all AI prompts, language models don't always perfectly follow skill files, so does the Humanizer actually work? In our limited testing, Chen's skill file made the AI agent's output sound less precise and more casual, but it could have some drawbacks: it won't improve factuality and might harm coding ability.

In particular, some of Humanizer's instructions might lead you astray depending on the task. For example, the Humanizer skill includes the line: "Have opinions. Don't just report facts - react to them. 'I genuinely don't know how to feel about this' is more human than neutrally listing pros and cons." While being imperfect seems human, this kind of advice would probably not do you any favors if you were using Claude to write technical documentation.

Even with its drawbacks, it's ironic that one of the web's most referenced rule sets for detecting AI-assisted writing may help some people subvert it.

Spotting the patterns

So what does AI writing look like? The Wikipedia guide is specific with many examples, but we'll give you just one here for brevity's sake.

Some chatbots love to pump up their subjects with phrases like "marking a pivotal moment" or "stands as a testament to," according to the guide. They write like tourism brochures, calling views "breathtaking" and describing towns as "nestled within" scenic regions. They tack "-ing" phrases onto the end of sentences to sound analytical: "symbolizing the region's commitment to innovation."

To work around those rules, the Humanizer skill tells Claude to replace inflated language with plain facts and offers this example transformation:

Before: "The Statistical Institute of Catalonia was officially established in 1989, marking a pivotal moment in the evolution of regional statistics in Spain."

After: "The Statistical Institute of Catalonia was established in 1989 to collect and publish regional statistics."

Claude will read that and do its best as a pattern-matching machine to create an output that matches the context of the conversation or task at hand.

An example of why AI writing detection fails

Even with such a confident set of rules crafted by Wikipedia editors, we've previously written about why AI writing detectors don't work reliably: There is nothing inherently unique about human writing that reliably differentiates it from LLM writing.

One reason is that even though most AI language models tend toward certain types of language, they can also be prompted to avoid them, as with the Humanizer skill. (Although sometimes it's very difficult, as OpenAI found in its yearslong struggle against the em dash.)

Also, humans can write in chatbot-like ways. For example, this article likely contains some "AI-written traits" that trigger AI detectors even though it was written by a professional writer—especially if we use even a single em dash—because most LLMs picked up writing techniques from examples of professional writing scraped from the web.

Along those lines, the Wikipedia guide has a caveat worth noting: While the list points out some obvious tells of, say, unaltered ChatGPT usage, it's still composed of observations, not ironclad rules. A 2025 preprint cited on the page found that heavy users of large language models correctly spot AI-generated articles about 90 percent of the time. That sounds great until you realize that 10 percent are false positives, which is enough to potentially throw out some quality writing in pursuit of detecting AI slop.

Taking a step back, that probably means AI detection work might need to go deeper than flagging particular phrasing and delve (see what I did there?) more into the substantive factual content of the work itself.

Read full article

Comments

An anonymous reader quotes a report from the Electronic Frontier Foundation (EFF): Lawmakers in Washington are once again focusing on kids, screens, and mental health. But according to Congress, Big Tech is somehow both the problem and the solution. The Senate Commerce Committee held a hearing [Friday] on "examining the effect of technology on America's youth." Witnesses warned about "addictive" online content, mental health, and kids spending too much time buried in screen. At the center of the debate is a bill from Sens. Ted Cruz (R-TX) and Brian Schatz (D-HI) called the Kids Off Social Media Act (KOSMA), which they say will protect children and "empower parents." That's a reasonable goal, especially at a time when many parents feel overwhelmed and nervous about how much time their kids spend on screens. But while the bill's press release contains soothing language, KOSMA doesn't actually give parents more control. Instead of respecting how most parents guide their kids towards healthy and educational content, KOSMA hands the control panel to Big Tech. That's right -- this bill would take power away from parents, and hand it over to the companies that lawmakers say are the problem. [...] This bill doesn't just set an age rule. It creates a legal duty for platforms to police families. Section 103(b) of the bill is blunt: if a platform knows a user is under 13, it "shall terminate any existing account or profile" belonging to that user. And "knows" doesn't just mean someone admits their age. The bill defines knowledge to include what is "fairly implied on the basis of objective circumstances" -- in other words, what a reasonable person would conclude from how the account is being used. The reality of how services would comply with KOSMA is clear: rather than risk liability for how they should have known a user was under 13, they will require all users to prove their age to ensure that they block anyone under 13. KOSMA contains no exceptions for parental consent, for family accounts, or for educational or supervised use. The vast majority of people policed by this bill won't be kids sneaking around -- it will be minors who are following their parents' guidance, and the parents themselves. Imagine a child using their parent's YouTube account to watch science videos about how a volcano works. If they were to leave a comment saying, "Cool video -- I'll show this to my 6th grade teacher!" and YouTube becomes aware of the comment, the platform now has clear signals that a child is using that account. It doesn't matter whether the parent gave permission. Under KOSMA, the company is legally required to act. To avoid violating KOSMA, it would likely lock, suspend, or terminate the account, or demand proof it belongs to an adult. That proof would likely mean asking for a scan of a government ID, biometric data, or some other form of intrusive verification, all to keep what is essentially a "family" account from being shut down. Violations of KOSMA are enforced by the FTC and state attorneys general. That's more than enough legal risk to make platforms err on the side of cutting people off. Platforms have no way to remove "just the kid" from a shared account. Their tools are blunt: freeze it, verify it, or delete it. Which means that even when a parent has explicitly approved and supervised their child's use, KOSMA forces Big Tech to override that family decision. [...] These companies don't know your family or your rules. They only know what their algorithms infer. Under KOSMA, those inferences carry the force of law. Rather than parents or teachers, decisions about who can be online, and for what purpose, will be made by corporate compliance teams and automated detection systems.

Read more of this story at Slashdot.